1. Field of the Invention
The present invention relates to a mechanism for keeping files synchronized in a multiple processor system that maintains more than one version of a given file.
2. Description of Related Art
In a data processing system which includes multiple service processors, each of which maintains its own version of a pre-specified plurality of data sets, it is necessary to keep those versions synchronized in order to facilitate a consistent handling of the resources of the data processing system in the event of transfer of control from one of the service processors to another. For the purposes of this application, the term "synchronized" means that versions of a given data set residing on different storage media in a data processing system, have identical contents.
In a system maintaining more than one version of a given data set, the requirement to keep data sets synchronized places the following burdens on the synchronizing system:
1. recognition that the versions of the data set are not the same;
2. selection of which version will be used as a master for the synchronizing process;
3. transfer of data from a designated source version to its counterpart target version in the other storage medium;
4. replacement of the target version in a way that maintains the integrity of the file in an environment in which the source and target versions may be changing;
5. prevention of loss of data which may occur because of disruption while a file synchronizing operation is in progress.
A prior art system in which file synchronization may be accomplished is exemplified by the UNIX operating system developed by AT&T, Bell Laboratories. Using UNIX, one could recognize that files are not synchronized by coding a synchronization status using existing file protection bits located in the UNIX inode. However, use of these file protection bits would have the following problems:
1. use of the protection bits for file protection, their intended purpose, would be restricted for files which must be kept synchronized;
2. the protection bits, if used for the dual purpose of recording file synchronization status and for file protection, would have to be manipulated by every application program which modifies the contents of the files;
3. when changing the status of a file from "not synchronized" to "synchronized," there is a critical section of the process during which a higher priority process could be scheduled to run. If this higher priority process modifies the contents of the file, and then marks the file status as "not synchronized," the file status will be incorrectly overwritten when the lower priority process resumes execution and marks the file status as "synchronized."
As an alternative, a separate synchronization record file could be maintained, with the obvious pitfall that the actual file status could be modified without updating the record file if system operations are interrupted by a machine fault or other operator action.
In the UNIX operating system, there is no mechanism to replace one file with another in a way which guarantees that the file contents will not be lost if the operation is interrupted. Therefore, the fourth burden on the synchronization algorithm cannot be safely overcome.
The usual method for replacing files in operating systems with UNIX system calls is to:
1. UNLINK the target file name, having the effect of deleting the file name such that no application program will have access to the file;
2. LINK the target file name to the replacement file. After this operation, the contents of the replacement file can be accessed by using either the target file name or the replacement file name. Only one data set exists, but it is accessible with both names.
3. UNLINK the replacement file name. This operation removes the extra name for the file, such that the data set is now only accessible by the original target file name.
It is apparent that this mechanism is insufficient because there is a window during which a processor outage could leave the system without a critical system file. After the first UNLINK step but before the LINK has completed, the system has no access to the target file because the old version has been deleted and the replacement version has yet to be renamed to the target filename.